Telegram Group & Telegram Channel
👣 Graceful Shutdown in Go

Любое приложение должно при завершении работы:

1. Закрыть точку входа (HTTP-сервер, очередь сообщений и т.д.), но сохранить исходящие соединения (БД, кэш) активными.
2. Дождаться окончания всех текущих запросов, и при превышении допустимого времени вернуть корректную ошибку.
3. Освободить критические ресурсы (соединения с БД, файловые блокировки, слушатели). :contentReference[oaicite:0]{index=0}

## 1. Обработка сигналов

В Unix-системах сигналы (`SIGTERM`, SIGINT, SIGHUP`) — это программные прерывания, уведомляющие процесс о необходимости завершения или перезагрузки конфигурации. По умолчанию Go-рантайм ловит многие сигналы, но для «мягкой» остановки обычно интересуют только `SIGTERM и SIGINT. :contentReference[oaicite:1]{index=1}


func main() {
// 1) Создаем канал для сигналов
signalChan := make(chan os.Signal, 1)
signal.Notify(signalChan, syscall.SIGINT, syscall.SIGTERM)

// 2) Запускаем сервер и другую работу здесь...

// 3) Ждем сигнала
<-signalChan
fmt.Println("Received termination signal, shutting down…")
}


2. Таймаут для завершения
В Kubernetes по умолчанию даётся 30 секунд на грациозную остановку (terminationGracePeriodSeconds). Хорошей практикой является резервирование 20 % времени (примерно 6 секунд) на «подстраховку» завершения.


timeout := 25 * time.Second
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()

if err := server.Shutdown(ctx); err != nil {
log.Fatalf("Server forced to shutdown: %v", err)
}


3. Остановка приёма новых запросов
Метод http.Server.Shutdown закрывает
слушатели и не принимает новые соединения, при этом дожидаясь окончания активных хэндлеров. Однако в контейнеризированных окружениях нужно сначала «провалить» readiness-пробу, чтобы снять под из балансировщика, и только затем вызывать Shutdown.
VictoriaMetrics


var shuttingDown atomic.Bool

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
if shuttingDown.Load() {
w.WriteHeader(http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
})

// При получении сигнала:
shuttingDown.Store(true)
// Ждем несколько секунд, пока traffic прекратится
time.Sleep(5 * time.Second)
server.Shutdown(ctx)


4. Обработка активных запросов
После вызова Shutdown(ctx) сервер ждет либо завершения всех соединений, либо истечения контекста. Чтобы уведомить свои хэндлеры о «скоро закрытии», используйте контекст:

a) Middleware с каналом отмены

func WithGracefulShutdown(next http.Handler, cancelCh <-chan struct{}) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx, cancel := WithCancellation(r.Context(), cancelCh)
defer cancel()
next.ServeHTTP(w, r.WithContext(ctx))
})
}

b) BaseContext для всего сервера


ongoingCtx, cancelFn := context.WithCancel(context.Background())
server := &http.Server{
Addr: ":8080",
Handler: yourHandler,
BaseContext: func(_ net.Listener) context.Context { return ongoingCtx },
}
// После готовности к остановке:
cancelFn()
VictoriaMetrics


5. Освобождение ресурсов
Не закрывайте ресурсы сразу при получении сигнала — хэндлеры могут ими ещё пользоваться. Лучше дождаться окончания работы (или таймаута), а затем в обратном порядке инициализации вызвать Close. Стандартный приём в Go — defer:


db := connectDB()
defer db.Close()

cache := connectCache()
defer cache.Close()

ОС сама освободит память и файловые дескрипторы при завершении процесса, но для внешних систем (БД, брокеры сообщений) рекомендуются явные Close()/Flush() для корректного завершения транзакций и избежания потерь данных.
VictoriaMetrics

➡️ Таким образом, грациозная остановка Go-приложения сводится к трём шагам:

- Ловим нужные сигналы и переключаемся на собственную логику.
- Останавливаем приём новых запросов через Shutdown и/или провал readiness-пробы.
- Ждём завершения активных запросов в пределах таймаута и закрываем ресурсы в обратном порядке.

@golang_books
Please open Telegram to view this post
VIEW IN TELEGRAM



tg-me.com/golang_books/970
Create:
Last Update:

👣 Graceful Shutdown in Go

Любое приложение должно при завершении работы:

1. Закрыть точку входа (HTTP-сервер, очередь сообщений и т.д.), но сохранить исходящие соединения (БД, кэш) активными.
2. Дождаться окончания всех текущих запросов, и при превышении допустимого времени вернуть корректную ошибку.
3. Освободить критические ресурсы (соединения с БД, файловые блокировки, слушатели). :contentReference[oaicite:0]{index=0}

## 1. Обработка сигналов

В Unix-системах сигналы (`SIGTERM`, SIGINT, SIGHUP`) — это программные прерывания, уведомляющие процесс о необходимости завершения или перезагрузки конфигурации. По умолчанию Go-рантайм ловит многие сигналы, но для «мягкой» остановки обычно интересуют только `SIGTERM и SIGINT. :contentReference[oaicite:1]{index=1}


func main() {
// 1) Создаем канал для сигналов
signalChan := make(chan os.Signal, 1)
signal.Notify(signalChan, syscall.SIGINT, syscall.SIGTERM)

// 2) Запускаем сервер и другую работу здесь...

// 3) Ждем сигнала
<-signalChan
fmt.Println("Received termination signal, shutting down…")
}


2. Таймаут для завершения
В Kubernetes по умолчанию даётся 30 секунд на грациозную остановку (terminationGracePeriodSeconds). Хорошей практикой является резервирование 20 % времени (примерно 6 секунд) на «подстраховку» завершения.


timeout := 25 * time.Second
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()

if err := server.Shutdown(ctx); err != nil {
log.Fatalf("Server forced to shutdown: %v", err)
}


3. Остановка приёма новых запросов
Метод http.Server.Shutdown закрывает
слушатели и не принимает новые соединения, при этом дожидаясь окончания активных хэндлеров. Однако в контейнеризированных окружениях нужно сначала «провалить» readiness-пробу, чтобы снять под из балансировщика, и только затем вызывать Shutdown.
VictoriaMetrics


var shuttingDown atomic.Bool

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
if shuttingDown.Load() {
w.WriteHeader(http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
})

// При получении сигнала:
shuttingDown.Store(true)
// Ждем несколько секунд, пока traffic прекратится
time.Sleep(5 * time.Second)
server.Shutdown(ctx)


4. Обработка активных запросов
После вызова Shutdown(ctx) сервер ждет либо завершения всех соединений, либо истечения контекста. Чтобы уведомить свои хэндлеры о «скоро закрытии», используйте контекст:

a) Middleware с каналом отмены

func WithGracefulShutdown(next http.Handler, cancelCh <-chan struct{}) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx, cancel := WithCancellation(r.Context(), cancelCh)
defer cancel()
next.ServeHTTP(w, r.WithContext(ctx))
})
}

b) BaseContext для всего сервера


ongoingCtx, cancelFn := context.WithCancel(context.Background())
server := &http.Server{
Addr: ":8080",
Handler: yourHandler,
BaseContext: func(_ net.Listener) context.Context { return ongoingCtx },
}
// После готовности к остановке:
cancelFn()
VictoriaMetrics


5. Освобождение ресурсов
Не закрывайте ресурсы сразу при получении сигнала — хэндлеры могут ими ещё пользоваться. Лучше дождаться окончания работы (или таймаута), а затем в обратном порядке инициализации вызвать Close. Стандартный приём в Go — defer:


db := connectDB()
defer db.Close()

cache := connectCache()
defer cache.Close()

ОС сама освободит память и файловые дескрипторы при завершении процесса, но для внешних систем (БД, брокеры сообщений) рекомендуются явные Close()/Flush() для корректного завершения транзакций и избежания потерь данных.
VictoriaMetrics

➡️ Таким образом, грациозная остановка Go-приложения сводится к трём шагам:

- Ловим нужные сигналы и переключаемся на собственную логику.
- Останавливаем приём новых запросов через Shutdown и/или провал readiness-пробы.
- Ждём завершения активных запросов в пределах таймаута и закрываем ресурсы в обратном порядке.

@golang_books

BY Golang Books


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/golang_books/970

View MORE
Open in Telegram


Golang Books Telegram | DID YOU KNOW?

Date: |

Pinterest (PINS) Stock Sinks As Market Gains

Pinterest (PINS) closed at $71.75 in the latest trading session, marking a -0.18% move from the prior day. This change lagged the S&P 500's daily gain of 0.1%. Meanwhile, the Dow gained 0.9%, and the Nasdaq, a tech-heavy index, lost 0.59%. Heading into today, shares of the digital pinboard and shopping tool company had lost 17.41% over the past month, lagging the Computer and Technology sector's loss of 5.38% and the S&P 500's gain of 0.71% in that time. Investors will be hoping for strength from PINS as it approaches its next earnings release. The company is expected to report EPS of $0.07, up 170% from the prior-year quarter. Our most recent consensus estimate is calling for quarterly revenue of $467.87 million, up 72.05% from the year-ago period.

Start with a fresh view of investing strategy. The combination of risks and fads this quarter looks to be topping. That means the future is ready to move in.Likely, there will not be a wholesale shift. Company actions will aim to benefit from economic growth, inflationary pressures and a return of market-determined interest rates. In turn, all of that should drive the stock market and investment returns higher.

Golang Books from fr


Telegram Golang Books
FROM USA